perm filename MILLER.TO[P,JRA]1 blob sn#547793 filedate 1980-11-30 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	well mark, it's another 4am session. i am tired and grumped in general, so
C00012 ENDMK
CāŠ—;
well mark, it's another 4am session. i am tired and grumped in general, so
you get a dump of what's "grumping" me about this deal. this is meant  for
your reading only (probably too "raw" for truman, and not for anyone else)
... so go away all you mail hackers...

basically, the  solution  is  so tightly  constrained  that's  there's  no
solution.  of course that's my opinion; feel free to get another. as i see
it gene's criteria are:

1 a production quality lisp

2. portable to 10, LM, and others

3. defined by dec 31

4. cost significantly less than 400k

let D be the magic lisp

3. says  D  must  be  an existing  lisp;  quick  definitions  are  absurd,
particularly in  theface of  1. in  fact the  general task  of defining  a
production quality lisp is a long slow process in general; particularly if
one is to  attract outsiders like  maclipers and/or interlispers  --that's
one thing that bothered me about the proposal i drafted last may-june, and
one thing that apppealed to me about my october proposal.

existing lisps that  fit 1  are maclisp and  interlisp dialects.   period.
standard lisp and  vlisp are interesting  and are possible  bases for  the
proposal that is mess  derived, but are NOT  suitable as stated  (standard
lisp is portable but not production quality; similar to vlisp. in fact the
inadequacy of vlisp led me to tlc-lisp --- and tlc-lisp as it is currently
defined is notsuitable either)

superficially 1,2,3 imply that D  is LM lisp, but  how do you separate  LM
lisp from LM? a. there's all the display stuff that makes LM LISP so nice,
and there's  the  12-16K od  micro  code  that violates  the  MACRO  level
portable machine.  (btw, all this is spelled out very politely in a  paper
-- you get the "no bullshit" variety this am) and what do you port to  the
10?

so what about NIL? well portability is not well defined yet. besides, as i
mentioned in the may-june  proposal, i feel NIL  is too baroque. in  fact,
that's the whole problem  with this set on  constraints:  they imply  that
lisp technology  is  a  nicely  canned and  packaaged  collection  of  bnf
equations and  documents that  tells the  truth. LISP  IS A  MESS, and  my
efforts at tlc are (converging to "were") aimed specifically at  finessing
the mess  and establishing  a decent  standard without  going through  the
pointless bullshit  meetings that  the lisp  standards people  seem to  be
attempting; unfortunately,  such ventures  take money,  time, and  people;
unfortunately, i don't have any of the above, and response this year makes
me have  considerable doubts  where or  not another  year of  $5000  gross
income is worth it....  anyway, if NIL is  to be a D, then buy a piece  of
mit (everyone else is)

the cleanest work so far is interlisp at parc, but it suffers from as many
hacks and historical warts as the rest of them. however, given the current
constraints, it really does look like a better basis than the conpetitors.
in particular, it  is maintained by  collection of people  whose state  of
equilibrium appears somewhat more  stable than the competition.   (please,
sir what is lisp machine lisp today? ans: "on which machine" -- i told you
i was in a  evil mode/mood) of course,  then there's the cost  constraint:
even transfering interlisp  to the vax  is estimated to  take at best  two
years, and maybe four (with one  year down already). and that's using  the
most portable of the extant lisp's (fitting 1-3). that's damn expensive.

what's to happen? well,  perhaps the lisp people  will sit around  pissing
and moaning at each other, protecting their private dialectcal dung hills,
while the pascal people rally around the S&M standard ADA and the creative
ones ignore  LISP  and take  to  the  well defined  and  soon  ubiquitious
smalltalk. of course,  the lisp people  can look up  occasionally and  say
"... but we did that in lisp in 1960", while the five little  smalltalk-80
piggies go "hee-hee-hee" all the way to the bank.

i think a lot of the probelm stems from trying to retrofit history, rather
than start over... consider scheme, for example. as an analogy, when a car
manufacturer wants a new model, they  don't go get last year's models  and
hack, patch, and modify  to make the new  issue (even chrysler doesn't  do
that); they start  over, saving  those segments  of the  design that  were
deemed useful and  chuck the  rest. unfortunately to  constraints for  the
magically lisp don't allow this.

what's to do with weaker constraints?  first, it is presumptious folly  to
assume we can spawn fully grown a "production lisp"; that must be done  by
experimentation and takes time; that was the basis of my october  proposal
and we all know where that led.

so the "fall back" position is to bandage a portable production system out
of the current rubble. i opt for attempting a subset i call VML that  will
support an interesting part of interlisp and maclisp, and given this  VML,
define a VM that is portble. of course  the trick is to find a useful  VML
(if one exists) --that's  part of the lisp  standards swamp. i may  attend
that meeting if i can afford it.


...enough of this.  i  must get back  to the proposal; i  will ship you  a
polite version of all this later today. be warned; it is expensive and  is
predicated on the  presumption that appropriate  people are available  now
and not "growable".

unfortunately, i feel  the best  course for  all concerned  --you, me  and
lisp-- was what i proposed  in october.  however, considering the  general
reaction to  my  ideas (ti  is  not alone)  i  have serious  doubts  about
fighting this battle at all. sorry to be in such a shitty mood, but looking
at the financial, educational and technical future does  not lead to optimism.


						john